IBIS Macromodel Task Group Meeting date: 20 February 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte SPISim: Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Arpad and Mike L. to fold changes discussed during the meeting into draft17_v2 to create draft17_v3. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Radek: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD189: - Arpad: [sharing his 'BIRD158 and BIRD189 Referencing Problems' presentation] - Radek suggested that we all take an AR to discuss compatibility problems between BIRD189 and BIRD158. - I think we do have a potential problem. - [slide 1] - Shows the three circuit topology drawings from BIRD158. - It also includes the "Note:" that appears 3 times in BIRD158 regarding the triangle symbols representing the same node. - Typically that node is node 0. - We don't enforce it as node 0, but the key is that they represent the same node. - [slide 2] - Illustrates what a combination of the two BIRDs could do. - Uses Vladimir's notation from his S-parameters presentation at the DesignCon IBIS Summit. Dotted lines explicitly indicate the reference terminal for each port. - Illustrates that for BIRD158 the reference node is most likely node 0 (though not required), but in BIRD189 there is no requirement for what node the reference terminals should be connected to. - This example shows a BIRD189 on-die model with different reference than the BIRD158 model. This is valid according to the syntax but could be mathematically problematic. - [slide 3] - An abridged version of the entire end-to-end flow. - Not even showing the reference for the channel model, since the EDA tool could do what it wants. - Every block could potentially have a different reference. - Big question is: How could we guarantee this won't happen? - The only thing we have right now on this subject is the BIRD158 Note. - [slide 4] - Recommendation from Vladimir - I thought we might consider a strict rule requiring all the reference nodes to be node 0. - Vladimir thought this would be too restrictive. He proposed this N+2 syntax (different reference terminal for the left (input) and right (output) terminals, so connected blocks can share the same reference for their connected terminals). - This makes it easier to connect the blocks (one reference on each side). - It also makes it conceptually closer to the way data would be measured. - Discussion: Radek agreed with the slide 1 statements. For slide 2 he noted that what was depicted (PD_ref and Vss_pin used as references) would be wrong unless information in the BIRD189 model described the connectivity of those nodes, or unless the Touchstone data met specific conditions that meant that no current flows to those reference nodes. Radek referred to his previous comments that if the N+1st reference node could be connected to something outside of the modeling area, then there must be no current flowing through that node (see 2017/11/14 ATM minutes, for example). Radek noted that Arpad's figures did not address another issue with BIRD189 in the context of BIRD158: BIRD189 models might contain power pin information, while BIRD158 was confined to I/O pins. Radek noted that this issue might need to be addressed more urgently than any referencing issue. Radek noted that the N+2 proposal was similar to a W-element configuration. He said this was okay, but noted that even Vladimir's presentation had pointed out that this could lead to an under-determined system, and we gained nothing by having different ends of the channel having different references. He noted that in other contexts we had decided to stick with the N+1 scheme. Bob noted that slide 2 illustrated two potential problems. The connection between the first two blocks showed a potential issue with BIRD158 connecting to BIRD189. The second connection showed potential inconsistencies within a BIRD189 Interconnect Model Set. He also noted that an N+2 scheme would be a significant syntax change. Arpad noted a concern that no matter what we did in these BIRDs we can't prevent one model maker who made the Tx and another model maker who made the Rx from having inconsistent referencing conventions. Radek said this was not an issue, and the user connects the model to the channel and has all the options they need for defining the reference. It's up to the tool/user to connect the references properly. Radek noted that even IBIS-ISS would have to be extended to support the N+2 proposal. Arpad noted that this wasn't really an issue in this discussion. IBIS-ISS could be improved in that regard, but BIRD158 explicitly skips the use of an IBIS-ISS wrapper, and if the model maker is using an IBIS-ISS wrapper in BIRD189 they are free to define the ports as they wish. Arpad said he thought the question for us at this point was whether we should mandate the node 0 reference or consider the N+2 proposal. Radek said he would prefer we not mandate node 0. He preferred that we maintain the A_gnd syntax for BIRD189 to define a common reference, but that it not be forced to be node 0. Walter noted that he thought the entire discussion was a waste of time. He said that in practice everyone uses node 0 as the reference for their S-parameter simulations, except possibly in power aware simulations. Since BIRD158 simulations are clearly not power aware, using anything other than node 0 didn't make sense. Similarly, for BIRD189, if you're using the Touchstone file shortcut then node 0 should be the reference. Arpad asked why why the N+1 solution was used for the shortcut? Walter said he had originally proposed an N terminal solution with node 0 assumed as the reference, but others objected. Radek reiterated that very specific conditions had to be met by the data in a Touchstone file if you were going to assume the reference terminal could just be connected to any node outside of the modeled area. In that case the reference terminal had to be isolated from the other terminals in the device. Radek gave the example of a simple resistor. He said if you made a one port model for the resistor, you would not assume you could connect that reference terminal to any old node and not affect the simulation results. Walter noted that you should model that resistor with a 2 port model. Radek agreed that it could be done that way, and said this model would meet the strict mathematical requirements he wanted to add to the language of the spec. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 27 February 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives